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Description 

[0001] The invention relates generally to computer 
systems and networks, and deals more particularly with 
a file manager for files which are shared by heteroge- 
neous clients that exhibit different communication pro- 
tocols. 

[0002] A local area network (LAN) was previously 
known which includes multiple homogeneous clients 
and a network server. For example, the clients on one 
network can all exhibit a network file system (NFS) pro- 
tocol or can all exhibit a server message block (SMB) 
protocol. Each of the clients comprises a personal com- 
puter or workstation with an operating system such as 
an IBM DOS or AT&T UNIX operating system or IBM 
OS/2 operating system, and a network adapter card 
(such as a Token-ring or Ethernet adapter card) and a 
client program which interfaces the personal computer 
or workstation to the other clients and the network serv- 
er. The network server also comprises a personal com- 
puter or workstation with an operating system such as 
IBM OS/2 operating system or a Novell Netware oper- 
ating system, and a network adapter card and a network 
server program which interfaces the personal computer 
or workstation of the network server to the other clients 
and provides various services to the clients. For exam- 
ple, the network server manages a common storage 
disk, printer and modem. Thus, any of the clients can 
read from and write to a common directory and common 
files which are stored on the common storage disk, use 
the printer and communicate over the modem. 
[0003] An IBM VM/ECF program executing in an IBM 
System/370 host computer was also previously known 
which provides services to multiple homogeneous cli- 
ents exhibiting a Server-Requester Programming Inter- 
face (SRPI) protocol. In this system, each client is logi- 
cally coupled to, assigned to and serviced by a different 
virtual machine within the host computer, and the virtual 
machine for each client manages a resource or resourc- 
es dedicated to the client. 

[0004] An IBM VM/NFS program executing in an IBM 
System/370 host computer was also previously known 
which provides services to multiple homogeneous cli- 
ents exhibiting an NFS protocol. In this system, each 
client can communicate with one or more host comput- 
ers to obtain services from the host computer. For ex- 
ample, each of the host computers provides a file man- 
ager common to all of the clients. The common file man- 
ager services NFS client requests by transforming the 
NFS protocol to a CMS protocol. However, the file man- 
ager supports only those NFS data formats which are 
compatible with CMS. 

[0005] Another previously known Novell Netware 3.1 
computer network comprises two local area networks, 
one supporting clients which all exhibit the NFS protocol 
and execute AT&T's Unix operating system, and the oth- 
er supporting clients which all exhibit a Novell SPX pro- 
tocol and execute DOS or OS/2 operating system. Al- 
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ternately, the different clients can all reside in the same 
network. Each of the networks or the sole network in the 
alternate case is coupled to a common server which has 
a different protocol converter for each client protocol 
5 type, in the foregoing example, one for the NFS protocol 
clients, and the other for the SPX clients. Each of the 
protocol converters interprets the requests from the re- 
spective client types and performs the file system oper- 
ation. While there is one file manager for all protocol 
10 converters and client types, there is a separate file name 
space for the names of files created by the clients of 
each protocol type. The file name spaces also include 
pointers from each file name in the name space to a stor- 
age location on a common disk. The file manager sup- 
15 ports a request by a human network service administra- 
tor to link the file names in one file name space to the 
other file name space. Pursuant to such a request, the 
file manager will copy the names and associated point- 
ers from the one name space to the other name space. 
20 After such linking, the clients associated with this other 
name space can read, change or delete the file names 
in this other name space and read from and write to the 
files which were linked from the one name space. Nev- 
ertheless, the clients associated with this other name 
2$ space cannot access the one name space and probably 
not delete files which were linked from the one name 
space. Also, this system includes a lock manager (or 
managers) which associates locks with file names within 
one name space only. Consequently, if the lock manager 
50 is called to place a lock on a file or file name (in one 
name space) that is the subject of a client request, the 
file name is not locked on the other name space so that 
clients associated with this other name space can simul- 
taneously access the same file. The lock is only effective 
35 against clients of the same type or the client that made 
the request causing the lock to be established, and 
which use the same name space. 
[0006] A general object of the present invention is to 
provide a system for true sharing of files between net- 
40 erogeneous clients. 

[0007] Another general object of the present invention 
is to provide a system of the foregoing type which in- 
cludes a true lock manager. 

[0008] Another object of the present invention is to 
45 provide a system of the foregoing type which also sup- 
ports files which are dedicated to each client. 
[0009] These and other objects are solved advanta- 
geously by the invention as claimsed. 
[0010] The invention resides in a computer system for 
so managing files or other data objects shared by first and 
second heterogeneous clients. The first client exhibits 
a first protocol and the second client exhibits a second, 
different protocol. The system comprises a first protocol 
converter which receives requests from the first client in 
55 to create, read and update the files or other data objects, 
and converts the requests to corresponding requests in 
a common protocol. The system also comprises a sec- 
ond protocol converter which receives requests from the 
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second client to create, read and update the files or oth- 
er data objects, and converts the requests to corre- 
sponding requests in the common protocol. The system 
also comprises a file manager common to both clients 
and both protocol converters, which receives the con- s 
verted requests exhibiting the common protocol and ex- 
ecutes the requests in a name space and data area 
which are both common to the first and second clients. 
The name space stores names of the files or other data 
objects and the data area stores the files or other data 10 
objects. The file manager provides access by each of 
the clients to names of files or other data objects created 
by the other client, and access by each of the clients to 
the files or other data objects written by the other client. 
[0011] According to one feature of the present inven- is 
tion, the system further comprises a common lock man- 
ager for the common name space and common data ar- 
ea. 

[001 2] According to another feature of the present in- 
vention, the system further comprises a second name 20 
space for names of other files or other data objects and 
a second data area for storing these other files or other 
data objects. The second name space and second data 
area are dedicated to the first client and not accessible 
by the second client. The first protocol converter re- 25 
ceives requests from the first client to access the second 
name space and second data area, converts the re- 
quests to the common protocol, and passes the convert- 
ed requests to the file manager for execution. The sys- 
tem also comprises a third name space for names of 30 
other files or other data objects and a third data area for 
storing these other files or other data objects. The third 
name space and third data area are dedicated to the 
second client and not accessible by the first client. The 
second protocol converter receives requests from the 35 
second client to access the third name space and third 
data area, converts the requests to the common proto- 
col, and passes the converted requests to the file man- 
ager for execution. 

[0013] The invention will be described in more detail 40 
by the following description in connection with embodi- 
ments shown in the drawing in which: 

Fig. 1 is a block diagram of a host computer which 
includes a file manager and lock manager accord- 45 
ing to the present invention, and heterogeneous cli- 
ents served by the file manager and lock manager; 

Figs. 2(a-c) form a flow chart which illustrates oper- 
ation of the file manager and lock manager of Fig. so 
t in response to specific requests from the clients; 

Figs. 3(a-f) is a flow chart which illustrates general 
operation of an SMB type of protocol converter with- 
in the file manager of Fig. 1 ; ss 

Figs. 4(a-e) is a flow chart which illustrates general 
operation of an NFS type of protocol converter with- 



in the file manager of Fig. 1 ; and 

Figs. 5(a-e) is a flow chart which illustrates general 
operation of a CMS type of protocol converter within 
the file manager of Fig. 1. 

Detailed Description of Embodiments 

[0014] Referring now to the drawings in detail wherein 
like reference numerals indicate like elements through- 
out the several views, Fig. 1 illustrates a computer net- 
work generally designated 10 which comprises a host 
computer 12 according to the present invention, and 
multiple heterogeneous clients 14a,b, 16 and 18 cou- 
pled to the host computer. Clients 1 4a, b exhibit one type 
of protocol such as SMB, client 1 6 exhibits another type 
of protocol such as NFS, and client 18 exhibits still an- 
other type of protocol such as AFS by Transarc Corp, 
SPX or AFP by Apple Computer Co. However, in the 
illustrated example, client 14a exhibits a DOS or OS/2 
1 .1 subtype of SMB protocol and client 14b exhibits an 
OS/2 1.2 subtype of SMB protocol. A "protocol" has 
three components, i.e. rules of communication, com- 
mand format and data format. The rules of communica- 
tion define what operations are expected from each type 
of command, the sequence of the operations and replies 
or returns to the requestor after each operation is per- 
formed. Specific command and data formats are de- 
scribed below. 

[001 5] Each of the clients 1 4a,b comprises a personal 
computer or workstation with an adapter card such as 
a Token-Ring adapter card and a client portion of net- 
work code such as IBM PC LAN Program or IBM DOS 
LAN Requester program to permit the personal compu- 
ter or workstation to interface to the other clients and a 
network server 25. The network server also comprises 
a personal computer or workstation with a Token-Ring 
adapter card and a server portion of network code such 
as an IBM OS/2 LAN Server 2.0 program. The network 
server provides various services to the clients including 
communication to host computer 12. To support such 
communication, the network server includes a previous- 
ly known parallel channel adapter (PCA) card (which is 
available from International Business Machines Corp.) 
and the host computer 12 includes a Block Multiplexor 
Channel which is described in detail in a document en- 
titled System/370 Principles of Operation which is avail- 
able from International Business Machines Corp. at Me- 
chanicsburg, Pa by order number G A22-7000. The PCA 
card is also described in copending patent application 
entitled "Network Server For Local And Remote Re- 
sources", filed 04/17/92, by Donald N. Jones et al., US 
Serial No. 07/870 026, which patent application is here- 
by incorporated by reference as part of the present dis- 
closure. Each of the clients 16 and 18 comprises a per- 
sonal computer or workstation with an adapter card 
such as an Ethernet adapter card and a client portion of 
network code to permit the personal computer or work- 
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station to interface to the other client. The clients 16 and 
18 are coupled to the host computer 12 by a TCP/IP 
communication link. 

[001 6] By way of example, host computer 12 is an IBM 
System/370 or System/390 computer with a VM/ESA s 
operating system. Host computer 1 2 manages direct ac- 
cess storage devices (DASDs) 20-23 for access by the 
clients 14a,b, 16 and 18 anda host application program 
26. In the illustrated embodiment, DASD 20 stores di- 
rectories and files in a data format native to the host 10 
computer, for example, a CMS data format using EBCD- 
IC characters. 

[0017] The host application program 26 uses a CMS 
protocol (i.e. CMS communication rules, a CMS com- 
mand format and the CMS data format), and can access 15 
DASD 20 via a protocol converter 46 and file (and direc- 
tory) manager 30. The CMS command format uses file 
system comands and/or macros such as FSOPEN, FS- 
CLOSE, FSREAD, FS WRITE, or the callable services 
library functions such as DMSOPEN, which are docu- 20 
mented in the VM/ESA Application Reference, from IBM 
Corp. in Mechanicsburg, Pennsylvania (order number 
ST00-5036). 

[0018] The CMS data format for file name and other 
data has the following limitations: eight characters per 2s 
file name, eight characters per file type, upper case let- 
ters, and other characters as set forth in the aforemen- 
tioned VM/ESA Application Reference, and no hierar- 
chical directories. Only the host application can access 
the directories and files in DASD 20. Such access is 30 
made via a file manager 30 and protocol converter 46 
which provides a communication rule conversion and a 
command format conversion to common communica- 
tion rules and common command format of a common 
application program interface (API) 50. The protocol 35 
converter calls the file manager 30 to access DASD 20 
using the common API protocol. There is no data format 
conversion because the data is stored in the CMS data 
format. 

[0019] DASD 21 stores directories and files in the 40 
DOS and OS/2 1 .1 SMB data format for all SMB clients. 
As noted above, the clients 14a,b use the SMB protocol. 
The SMB command format comprises a header format 
which is common to all types of commands and a pa- 
rameter format which varies based on the type of pa- 45 
rameter. The parameter format is described in the doc- 
uments entitled 'Microsoft Networks/OpenNET File 
Sharing Protocol", Intel Part Number 138446 Version 
1.9, 04/21/87, Microsoft Corporation, Intel Corporation; 
"Microsoft Networks SMB FILE S HATING PROTOCOL 50 
EXTENSIONS: SMB File Sharing Protocol Extensions 
Version 2.0", Document Version 3.2, 07/1 3/88, Microsoft 
Corporation; and "Microsoft Networks SMB FILE SHAR- 
ING PROTOCOL EXENTSIONS: SMB File Sharing 
Protocol Extensions Version 3.0", Document Version ss 
1.09, 11/29/89, Microsoft Corporation. The header for- 
mat is as follows: 

identifier of this command strucutre i.e. "SMB" 



network request or command code 
space for return code and error class when sending re- 
sponse flags to qualify operation 
additional flags to qualify operation 
flags reserved for host use to qualify operation 
fields used to identify a source, tree ID, caller's process 
ID, user ID in user level security mode - 
network (or host) server supplied tokens or han- 
dles for resource connection, account name, file name, 
and 

multiplexing correlation constant 
multiplex ID for request and response correlation 
[0020] The SMB data format uses ASCII characters 
with the following limitations: the DOS and OS/2 1 . 1 sub- 
type require a file name with a maximum of eight char- 
acters, a period, and then a file type with a maximum of 
three characters; the OS/2 1.2 subtype permit a file 
name with a maximum of two hundred fifty five charac- 
ters (and do not require a period or file type) per file 
name. The allowable characters in a file name are, for 
OS/2 1.2 clients, uppercase alphabetic, numberic, and 
any special characters except : 

" (double quote) 

: (colon) 

> (greater-than sign) 

< (less-than sign) 
I (or-bar) 

/ (forward slash) 
\ (backward slash) 

* (asterick) 

? (question mark) 
For DOS clients, upper case alphabetic characters, nu- 
meric charactrs (0-9) and any special characters except : 

" (double quote) 

: (colon) 

> (greater-than sign) 

< (less-than sign) 
I (or-bar) 

/ (forward slash) 
\ (backward slash) 

* (asterick) 

? (question mark) 
. (period) 
[ (left bracket) 
] (right bracket) 
+ (plus sign) 
= (equal sign) 
; (semicolon) 
, (comma) 

Only the SMB clients 14a,b can access the directories 
and files in DASD 21 . Such access is made via file man- 
ager 30 and a protocol converter 34 which provides a 
communication rule conversion and a command format 
conversion to the communication rules and comand for- 
mat of the common API. The protocol converter 34 calls 
the file manager 30 to access DASD 21 using the com- 
mon API protocol. There is no data format conversion 
because the data is stored in SMB data format. 
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[0021] DASD 22 stores directories and files in the 
NFS format. As noted above, the client 16 uses the NFS 
protocol (including the NFS rules of communication, 
NFS command format and NFS data format). The NFS 
protocol and accompanying data representations are 
documented in the following Internet "Request For Com- 
ments" (RFC) documents: 

for NFS -RFC #1094 

for RPC- RFC # 1057 

for XDR (External Data Representation): RF # 

1014. 

[0022] The NFS data format uses ASCII characters 
with much freedom, i.e. lowercase letters, capital letters 
and mixed letters, a maximum of two hundred fifty-five 
characters per file name and alphanumeric and symbol- 
ic characters are permitted. Only the NFS client 16 can 
access the directories and files in DASD 22. Such ac- 
cess is made via file manager 30 and a protocol con- 
verter 36 which provides communication rule conver- 
sion and command format conversion to the communi- 
cation rules and command format of the common API. 
The protocol converter 36 calls the file manager to ac- 
cess DASD 22 using the common API protocol. Ther is 
no data format conversion because the data is stored in 
NFS format. 

[0023] DASD 23 stores directories and files in a com- 
mon data format. The common data format uses ASCII 
characters, and includes the following capabilities: file 
names may consit only of the DOS SMB character set, 
but names may be up to 255 characters long. Hierarchi- 
cal directories are maintained. Any of the clients and 
host application program can access the directories and 
files in DASD 23 such that the directories and files are 
"shared", and such access is made via file manager 30 
and a respective protocol converter 34, 36 or 38 corre- 
sponding to the type of client 14a,b, 16 or 18, and pro- 
tocol converter 46 for host application program 26. The 
protocol converters call the file manager 30 to access 
DASD 23 using the common API protocol. However, a 
file name will not be furnished to a client if the syntax of 
the file name cannot be accepted by the client. For ex- 
ample, if the DOS or OS/2 1 . 1 SMB client type requests 
to read the directory, and the directory includes a file 
name with more than eight characters or no period with 
at least one character on either side, or more than three 
characters after the period, then the protocol converter 
will not include such a file name in the directory listing 
that is sent to the SMB client. The directories are stored 
in a common name space 27 within DASD 23. 
[0024] According to one object of the present inven- 
tion, the heterogeneous clients 14a,b, 16 and 18 and 
host application program 26 can ail access the shared 
directories and files in . DASD 23, as soon as they are 
written (and the writer completes its access if the other 
access is conflicting), and the shared access is total, i. 
e. as if the client created the file in its dedicated DASD. 
The clients make the access requests and receive re- 
plies without any change to the normal protocols exhib- 
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ited by these clients and host application program. The 
protocol converters 34, 36, 38 and 46 make the neces- 
sary conversion of protocol to that of the common API 
50 for the file manager 30. The data format for the com- 
5 mon API is described above. The command formats for 
the major commands of the common API followed by 
the respective return formats are as follows: 

Command: locate 
10 path token to locate directory that contains 

the file 
file name 

Return: token for file name 
is file token 

successful or unsuccessful search code: 



Command: open 

file token 

20 

Return: file attributes; 

Command: read 

file token 

25 read parameter list, i.e. offset into the file to 

start reading, number of bytes to read 
pointer to data buffer 



30 



Return: data; 

Command: write 

file token 

write parameter list, i.e. offset into file to 
start writing and number of bytes to write 
35 and pointer to data to write (included in re- 

quest) 

Return: successful or unsuccessful code; 

40 Command: close 

file token 

Return: successful or unsuccessful code; 

45 Command: create 

file token name 
attributes 

Return: successful or unsuccessful code; 

so 

Command: lock 

file token 

access/share type, i.e. read/write exclusive 
access read/write, share read only 
55 access write, share write 

access write, share read 
read only, share read and write 
read only, share write 
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read only, share read 

read only, share none 

write only, share read and write 

write only, share write 

write only, share read 

write only, share none 

read and write, share read and write 

read and write, share write 

read and write, share read 

read and write, share none 

Return: successful or unsuccessful code; and 

Command: unlock 
file token 

Return: successful or unsuccessful code. 

[0025] The communication rules for the principle com- 
mands are illustrated in Fig. 2(a-e) and described below. 
As described above, there is one protocol converter for 
each type of client that has access to the shared direc- 
tories and files. 

[0026] Figs. 2(a-e) illustrate operation of host compu- 
ter 12 (including the various protocol converters) in re- 
sponse to the major requests/commands by the heter- 
ogeneous clients 14a,b, 16 and 18 and host application 
program 26 to access the shared directories and files in 
DASD 23. In step 100, client 14a (which is SMB DOS 
type) makes a request using SMB protocol to create a 
file with name AAA.BBB and shared access, i.e. the file 
should be stored in DASD 23 and access permitted to 
all the clients 1 4a,b, 16 and 18 and host application pro- 
gram 26. The request also includes a file token which 
identifies DASD 23 and was obtained by the client pre- 
viously when the client requested a connection to the 
resource. The request is passed to protocol converter 
34 which supports (i.e. understands) the SMB DOS pro- 
tocol. Protocol converter 34 calls a processing routine 
within itself which corresponds to the type of command, 
and this processing routine handles the command. In 
this case, the processing routine makes a request using 
the common API protocol to the file manager, to locate 
the file name AAA.BBB and return a file token which 
identifies the file by location (path). Although the proto- 
col converter 34 has the capability to convert a file name 
in lower case letters to upper case letters, this was not 
necessary in this example because the file name was 
submitted by the client in upper case letters only. In re- 
sponse to the request, the file manager reads the direc- 
tory for the shared files from DASD 23, searches for the 
file name AAA. BBB, determines that this file name does 
not exist in the directory, and returns an indication to the 
protocol converter 34 that the file does not exist (step 
104), although it does reserve a token associated with 
the name and effectively will reserve a "place" for the 
file if it is later created. 

[0027] After receiving the return, the protocol convert- 



er 34 initiates the next component of the client create 
request by calling a lock manager program 105 (step 
1 06) which places a lock on the file (step 1 08). This lock 
(and all locks established by the lock manager 105 for 
5 a request to the shared files) applies to access by any 
and all clients to the file and file name. The protocol con- 
verter determines an appropriate level for the lock based 
on the client create request parameters, and specifies 
the level ("access/share status") in the call. This lock is 
10 associated with the file name and denies some or all 
access by all the other clients and application program 
to the named file, even though the file is not "created" 
yet. After establishing the lock, the lock manager returns 
control to the protocol converter 34. Next, the protocol 

f$ converter initiates the third component of the client cre- 
ate request by calling the file manager to actually create 
the file (step 1 1 0). The file manager then creates the file 
by making file directory entries and other control block 
structures for the file name (step 1 1 2). A directory entry 

20 113 indicates the existence of file AAA.BBB in DASD 
23, although the file does not yet have any data in it, just 
a file name. After creating the file, the file manager re- 
turns control to the protocol converter 34 which returns 
control to the client (step 114). 

25 [0028] Soon afterwards, and while the lock of step 1 08 
is still in place, the client 14a makes a request to the 
protocol converter 34 to write data into file AAA.BBB, 
and supplies the data which is to be written (step 116). 
The protocol converter calls the file manager with a write 

30 request and supplies a pointer to the data in the data 
buffer and an offset into the file at which the data should 
be stored (step 118). The file manager then determines 
a location in DASD 23 to store the file data and calls a 
DASD controller 119 to write the data from the location 

35 in the data buffer specified by the protocol converter to 
the location in DASD 23 determined by the file manager 
based on the file offset, and then returns control to the 
protocol converter (step 120). After the action of the 
DASD controller, the file name AAA.BBB and file data 

40 are stored in DASD 23 (status 121). The protocol con- 
verter then returns control to the client (step 124) which 
makes a request to protocol converter 34 to close the 
file AAA.BBB (step 130). In response, the protocol con- 
verter calls the file manager to close the file AAA. BBB 

45 (step 1 32), and the file manager closes the file by com- 
pleting the writing of data yet unwritten from the previous 
write request, and updating the aforesaid directory entry 
and control blocks (step 134). Then, the file manager 
returns control to the protocol converter, and the proto- 

so col converter calls the lock manager to unlock file AAA. 
BBB (step 1 36). The lock manager removes the lock and 
then returns control to the protocol converter (step 1 38) 
which returns control to the client (step 140). If the lock 
was an exclusive lock, any other client or host applica- 

ss tion program can now access the file name and file data. 
[0029] Subsequently, client 1 4b makes a request (us- 
ing SMB OS/2 1 .2 protocol) to protocol converter 34 to 
open file AAA.BBB (step 150). This step assumes that 
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client 14b previously learned of the existence of file 
AAA.8BB, for example, from another user. However, 
step 150 could have followed a request by client 14b to 
read the directory in DASD 23 for the shared files to 
learn of file AAA.BBB as described below in steps 
290-318. In response to the call, protocol converter 34 
determines if client 1 4b is authorized to access file AAA. 
BBB (step 1 52). This determination is required because 
client 14b did not create file AAA.BBB and is based on 
an authorization file for this client. Next, protocol con- 
verter 34 calls the lock manager 105 to place a lock on 
file AAA. BBB. The type of lock is read and share and is 
based on a parameter in the client request correspond- 
ing to the nature of the subsequent access contemplat- 
ed by the client to read the file. The lock manager es- 
tablishes the lock and returns to the protocol converter 
34 (step 154). Then, the protocol converter 34 calls the 
file manager to open file AAA.BBB (step 156), and the 
file manager complies by initializing access to the file, 
creating tokens for later access and updating the afore- 
said directory entry and control blocks (step 1 58). Then, 
the file manager returns control to the protocol converter 
34 which returns control to the client 14b (step 159). 
[0030] After receiving the return, the client 14b pro- 
ceeds to make a read request for file AAA.BBB to pro- 
tocol converter 34 (step 170). In response, the protocol 
converter calls the file manager to read the data in file 
AAA.BBB (step 172), and the file manager determines 
the location of the file by the aforesaid directory entry 
and control blocks, and calls the DASD controller 1 1 9 to 
read the contents of this location into data buffer 1 1 5 
(step 174). The read request does not change the con- 
tents of file AAA. BBB (status 176). 
[0031] After completing the read access, client 14b 
now makes a request to protocol converter 34 to close 
file AAA. BBB (step 180), and protocol converter 34 calls 
the file manager to close the file (step 1 82). The file man- 
ager complies by updating the aforesaid directory entry 
and control blocks (step 184). Then, the file manager 
returns to the protocol converter, and the protocol con- 
verter calls the lock manager to unlock file AAA.BBB 
(step 186). The lock manager removes the lock on file 
AAA.BBB, and then returns to the protocol converter 
(step 188), which returns to the client 14b (step 190). 
This concludes one instance of access by client 14b to 
the shared files. 

[0032] Next, client 16 (which exhibits NFS protocol) 
makes a request to host computer 1 2 to create a file with 
a file name CCCC.DDDD parameter and shared access 
parameter with the request (step 200). The request is 
received by a routing process 201 . The routing process 
detemines the type of client based on the communica- 
tion path over which the request is received, and passes 
the request to a type of protocol converter correspond- 
ing to the type of client In this example, the client ex- 
hibits NFS protocol, and therefore the routing process 
passes the request to protocol converter 36. In re- 
sponse, protocol converter 36 determines if client 16 



has the authority to access DASD 23 (step 202). Then 
protocol converter 36 calls the file manager 30 to locate 
the file name CCCC.DDDD to determine if the file name 
has already been used. In response, the file manager 
5 searches the directory for the shared files and deter- 
mines that this file name CCCC.DDDD is available (step 
204), and then returns to the protocol converter 36. 
Next, the protocol converter 36 calls the lock manager 
to lock the file name even though the file CCCC.DDDD 

io is not created yet (step 206). The lock manager 105 
places a lock on the file and then returns to the protocol 
converter 36 (step 208). Next, the protocol converter 
calls the file manager 30 to actually create the file (step 
210), and the file manager creates the file by creating 

15 another directory entry and associated control blocks 
(step 21 2). Then, the file manager returns to the protocol 
converter, which returns to the client (step 216). At this 
time, the shared files include the file name CCCC.DDDD 
but no data for this file (status 214). 

20 [0033] Soon after receiving the return, client 16 
makes a request to host computer 12 to write into file 
CCCC.DDDD and includes the data (step 220). The 
routing process 201 passes the request to protocol con- 
verter 36 which calls the file manager 30 to write the 

25 data into file CCCC.DDDD (step 222). In response, the 
file manager determines the location of file CCCC. 
DDDD, and then calls the DASD controller 119 with the 
data and address (step 224), and the DASD controller 
writes the data into file CCCC.DDDD. At this time, the 

30 shared files include file name CCCC.DDDD and the as- 
sociated data, as well as file name AAA. BBB and the 
associated data (status 226). Then, the file manager re- 
turns to the protocol converter 36 which calls the file 
manager to close file CCCC.DDDD (step 228). It should 

55 be noted that according to NFS protocol, the client does 
not supply either an open or close command; the open 
and close command are presumed to precede and fol- 
low each write operation. (This contrasts with SMB pro- 
tocol in which the SMB client must supply the close com- 

40 mand after a write command as illustrated in step 1 30 
above). The file manager closes the file and then returns 
to the protocol converter 36 (step 230). Next, the proto- 
col converter calls the lock manager to unlock file 
CCCC.DDDD (step 232). The lock manager complies 

45 and returns to the protocol converter (step 234), and the 
protocol converter returns to the client (step 236). 
[0034] Subsequently, the client 14b makes a request 
to protocol converter 34 to open file CCCC.DDDD (step 
240). This presumes that client 14b previously learned 

50 of the existence of file CCCC.DDDD. It should be noted 
that the SMB client 1 4b can open (and subsequently 
read from or write to) a file that was created and written 
by the NFS client 16. In response to the call, protocol 
converter 34 determines if client 1 4b has authority to ac- 

55 cess file CCCC.DDDD (step 242). If so, protocol con- 
verter 34 calls the lock manager 105 to lock file CCCC. 
DDDD, and the lock manager locks the file and returns 
to the protocol converter (step 244). Then, the protocol 
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converter calls the file manager to open file CCCC. 
DDDD (step 246), and the file manager complies by ac- 
cessing the file directory entry (step 248). Then, the file 
manager 248 returns to the protocol converter 34 which 
returns to the client (step 250). 
[0035] After receiving the return, client 14b makes a 
write request to protocol converter 34 and includes data 
and the file name CCCC.DDDD parameter (step 260). 
The data can be additional data for the file CCCC. 
DDDD, a change of the existing data, or deletion of the 
existing data. In response, the protocol converter calls 
the file manager 30 to write the data into the named file 
(step 262), and the file manager determines the location 
of the file in DASD 23 and calls the DASD controller 119 
supplying the data and address (step 264). The DASD 
controller writes the data into DASD 23, and the result 
is indicated as data' (status 266). Then, the file manager 
returns to the protocol converter 34, and the protocol 
converter returns to the client (step 268). Next, the client 
14b makes a close request to protocol converter 34 for 
file CCCC.DDDD (step 270), and protocol converter 34 
calls the file manager 30 to close file CCCC.DDDD (step 
272). In response, the file manager closes the file 
CCCC. DDDD and then returns to the protocol converter 
(step 274). Next, the protocol converter, calls the lock 
manager to unlock file CCCC.DDDD (step 276), the lock 
manager complies and returns to the protocol converter 
(step 278), and the protocol converter returns to the cli- 
ent (step 280). 

[0036] Subsequently, client 14b makes a request to 
protocol converter 34 to list all shared files (which re- 
quest is similar in concept to a request to read the di- 
rectory for the shared files) (step 290). In response, the 
protocol converter determines if client 14b has the au- 
thority to access all the files (step 292). Assuming client 
14b has such authority, the protocol converter calls the 
file manager for a token for the search directory. The 
token is the file manager's representation of the direc- 
tory to be searched. The file manager associates the 
shared file directory with the token by internal control 
blocks of the file manager, and then returns to the pro- 
tocol converter (step 294). Next, the protocol converter 
calls the lock manager to lock the search directory (step 
296), and the lock manager complies and returns to the 
protocol converter (step 298). Next, the protocol con- 
verter calls the file manager to read the directory into 
data buffer 115 for access by the file manager (step 
296). In response, the file manager determines the lo- 
cation of the directory, and sends a read command, the 
DASD address to read from and the data buffer address 
to receive the data, to the DASD controller 119 (step 
302), and then the DASD controller performs the read 
operation. Then, the file manager returns to the protocol 
converter and provides the address in the data buffer 
1 1 5 that stores the directory. Next, the protocol convert- 
er calls the lock manager to unlock the search directory 
(step 306), and the lock manager complies and returns 
to the protocol converter (step 308). Next, the protocol 



converter calls the file manager to release the search 
token (step 31 0), and the file manager disassociates the 
search token with this directory, and returns control to 
the protocol converter (step 312). Next, the protocol 

5 converter compares the file names read from DASD 23 
to search criteria specified by the client 1 4b in the search 
request (i.e. list all files) in step 290 (step 314). The 
search criteria can be a specific file, all files or all files 
with certain characters in their names. Then, the proto- 

10 col converter sends the file names that meet the criteria 
to the client, and returns control to the client (step 316). 
These file names are AAA.BBB and CCCC.DDDD. It 
should be noted that SMB client 14b is able to read the 
file name CCCC.DDDD that was created by NFS client 

15 16 (and write to the file data as described above and 
read from the file data). 

[0037] Subsequently, the client 14b makes a request 
to protocol converter 34 to rename file CCCC.DDDD to 
file name XXXX.YYYY (step 320). File CCCC.DDDD 

20 was created by client 1 6. In response, protocol convert- 
er 34 determines if client 14b is authorized to access 
this file, and then calls the file manager 30 to associate 
tokens with the directory and both old and new file 
names (this is actually three separate file manager calls) 

25 (step 321 ). The file manager then associates the direc- 
tory and file names with tokens, and returns the tokens 
to the protocol converter (step 322). Next, the protocol 
converter calls the lock manager to lock the directory 
(step 323), and the lock manager complies and returns 

30 an acknowledgement (step 324). Next, the protocol con- 
verter calls the file manager to change the file name 
CCCC.DDDD to XXXX.YYYY (step 325), and the file 
manager complies by changing the entry in the directory 
and the associated control block (step 326), and returns 

35 control. Then, the protocol converter calls the file man- 
ager to return the token (step 330), and in response, the 
file manager releases the directory and file tokens such 
that the tokens are no longer associated therewith, and 
returns control to the protocol converter (step 331). Fi- 

40 nally, the protocol converter returns control to the client 
with an acknowledgement that the file has been suc- 
cessfully renamed (step 332). 

[0038] Subsequently, the host application 26 makes 
a request to protocol converter 46 to open file AAA.BBB 

45 (step 338). In response, the protocol converter deter- 
mines if host application 26 is authorized to access file 
AAA.BBB, and assuming this is the case, calls the file 
manager to obtain a token for the file (step 339). The file 
manager associates the token with the file, and returns 

50 the token to the protocol converter (step 340). Next, the 
protocol converter calls the lock manager to lock the file 
(step 341 ), and the lock manager complies and returns 
control to the protocol converter (step 342). Next, the 
protocol converter calls the file manager to actually open 

55 the file (step 343). The file manager opens the file and 
returns control (step 344). Finally, the protocol converter 
returns control to the host application with an indication 
that the file has been opened (step 345). 
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[0039] Soon afterwards, the host application 26 
makes a request to the protocol converter 46 to write to 
file AAA. BBB that was just opened (step 350). The host 
application 26 provides the data with the request, and 
the data is temporarily stored in the data buffer 115. In 
response to the call, the protocol converter calls the file 
manager to write the data into DASD 23 (step 352), and 
the file manager complies with assistance from the 
DASD controller 1 1 9 and returns to the protocol convert- 
er (step 353). Then, the protocol converter returns to the 
host application with an indication that the data has been 
written successfully (step 354). Next, the host applica- 
tion makes a request to protocol converter 46 to close 
file AAA. BBB (step 355). In response, the protocol con- 
verter calls the file manager to close the file (step 356). 
The file manager complies and returns control (step 
357). Next, the protocol converter 358 calls the lock 
manager to unlock file AAA. BBB (step 358), and the lock 
manager complies and returns control (step 359). Next, 
the protocol converter calls the file manager to return 
the token associated with file AAA. BBB (step 360), and 
in response, the file manager disassociates the file from 
the token and returns to the protocol converter (step 
361). Finally, the protocol converter returns control to 
the host application with an indication that the file has 
been successfully closed (step 362). 
[0040] Subsequently, NFS client 16 makes a request 
to the host computer 12 to delete file AAA. BBB which 
was created by SMB client 14a (step 366). The routing 
process 201 routes the request to the corresponding 
protocol converter 36, which calls the file manager 30 
to obtain a token for the file AAA. BBB (step 367). The 
file manager associates a token with the file and returns 
it and control to the protocol converter (step 368). Next, 
the protocol converter 370 calls the lock manager to lock 
file AAA. BBB for deletion (step 370). Because the file 
will be deleted, the lock manager places an exclusive 
lock on the file, and then returns to the protocol convert- 
er (step 359). Next, the protocol converter calls the file 
manager to delete the file (step 374), and the file man- 
ager complies by erasing the file name AAA. BBB from 
the directory, erasing the associated control block, and 
erasing the data from the file (step 375). Next, the pro- 
tocol converter calls the lock manager to unlock the file 
AAA. BBB (step 378), and the lock manager complies 
and returns control (step 379). Next, the protocol con- 
verter calls the file manager to return the token for file 
AAA. BBB (step 380), and the file manager disassoci- 
ates the file from the token and returns control (step 
381 ). Finally, the protocol converter returns control to 
the client 1 6 with an indication that the file AAA.BBB has 
been deleted (step 382). 

[0041] In accordance with another object of the 
present invention, each of the clients 14a,b, 16 and 26 
can also access their private DASDs 21 ,21 , 22 and 20, 
respectively, using the same flows illustrated in Figs. 2 
(a-e). The only differences to the flows are that the client 
requests to create and list the private files specify one 



of the private DASDs (instead of shared access), each 
private file and directory is stored in the respective pri- 
vate DASD, and each private DASD does not include 
any files created by clients of the other types. The pri- 
5 vate files and file names within one DASD can only be 
accessed by clients of the one type. 
[0042] Figs. 3(a-e) illustrate the protocol converter 34 
function in more detail. In step 400, a remote request is 
received from one of the SMB clients 14a or 14b, 

10 through a communications routing function such as AP- 
PC/VM or directly through CP channel management. 
When the request is received, the protocol converter in- 
vokes the appropriate handler routine for the type of re- 
mote request (step 402). 

is [0043] A request to create a file is routed to an entry 
point 404 and then a decision 414 in which the protocol 
converter 34 determines if the client is authorized to add 
files to the shared files system, both in general and in 
particularly within a specified directory. If the client is not 

20 so authorized, then the protocol converter responds to 
the client with a failure indication -permission denied. 
However, if the user has the appropriate authorization, 
then the protocol converter folds the file name to upper 
case letters if the file name is submitted in lower case 

25 letters to conform to the data format of the shared files 
(step 416). Then the protocol converter calls the file 
manager to locate the file and return a handle or token 
based on the name (step 418). If the file already exists 
(decision 420), then the protocol converter responds to 

30 the client with a failure indication and performs appro- 
priate cleanup, including a call to the file manager to re- 
turn the token associated with the file (step 421). If the 
file does not already exist, then the protocol converter 
makes a call to the lock manger to lock the file token 

35 and structures associated with the file (step 422). Next, 
the protocol converter calls the file manager to create 
the file (step 423). If the file was successfully created 
(decision 424), then the protocol converter responds to 
the client with an indication of success and with the file 

40 attributes. However, if the file was not successfully cre- 
ated, then the protocol converter responds to the client 
with an indication of failure only. 
[0044] Referring again to Fig. 3(a), a request to open 
a file is routed to an entry point 406 and then a decision 

45 427 of Fig. 3(c) in which the protocol converter deter- 
mines if the client is authorized to open the named file. 
If not, then the protocol converter responds to the client 
with a failure indication and denial of permission to open 
the file. However, if the client is authorized, then the pro- 

50 tocol converter folds the file name to upper case if the 
name of the file to be opened is submitted in lower case 
letters to conform to the data format of the shared files 
(step 428). Then, the protocol converter calls the file 
manger 30 to locate the file and return a handle or token 

55 based on the name (step 430). If the file does not exist 
(step 432), then the file manager so notifies the protocol 
converter, and the protocol converter passes the re- 
sponse to the client indicating that the file cannot be 
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opened, performs the appropriate cleanup, and calls the 
file manager to return the token associated with the file 
(step 433). However, if the file exists, then the open re- 
quest can be performed and the protocol converter calls 
the lock manager to lock the file token and structures 
associated with the file (step 434). If the file is already 
locked by another client, and the lock excludes access 
by the client which just made the open request, then the 
lock manager responds to the protocol converter with a 
failure indication and the protocol converter passes this 
response to the client and performs appropriate cleanup 
(step 437). However, if the lock request is granted, then 
the protocol converter calls the file manager 30 to open 
the file (step 438). If the file manager then successfully 
opens the file (decision block 439), then the file manager 
indicates such to the protocol converter and the protocol 
converter passes the response to the client (step 440). 
[0045] Referring again to Fig. 3(a), a client request to 
read a file causes the protocol converter 34 to call an 
entry point 408 within itself. Then, the protocol converter 
performs a cursory authorization check to ensure that 
the remote request is legitimate and not an attack by a 
malicious client on the remote network (step 441). This 
check is made by comparison of values within the re- 
mote request with those known to have been assigned 
to the user by the protocol converter. Assuming that the 
client is authorized to make the read request (decision 
442), then the protocol converter calls the file manager 
to extract data from the file to be read and copy the data 
into the data buffer 1 1 5 (step 444). The file to be read in 
this case is the one that was previously created and 
opened, and is referenced by the client in the client re- 
quest by the token or handle that was returned to the 
client after the create and open requests were executed. 
The file manager responds to the protocol converter with 
an indication whether the file manager was successful 
in reading the data into the data buffer 115. If the file 
manager was successful (decision 445), then the pro- 
tocol converter responds to the client with an indication 
of success and the requested data (step 446). 
[0046] Referring again to Fig. 3(a), a client request to 
write into the file is passed to the protocol converter 34, 
and the protocol converter calls an entry point 41 0 within 
itself. The file to be written in this case is the same file 
that was previously created and opened, and for which 
the client received a token or handle after execution of 
the create and open operations. The client provides this 
token or handle with the write request. Then, the proto- 
col converter performs another cursory authorization 
check to determine if the client request is legitimate and 
not an attack by a malicious client on the remote network 
(step 448). The write request from the client also in- 
cludes client data which is written into the data buffer 
115. Assuming that the client is authorized to make the 
write request (decision 450), then the protocol converter 
34 calls the file manager to write the data from the buffer 
1 1 5 into the DASD 23 (step 452). The file manager calls 
the DASD controller 11 9 to assist in the write operation. 



[0047] Referring again to Fig. 3(a), a client request to 
search, i.e. a request to retrieve a list of names of files 
and other objects within the directory for the shared files, 
is passed to the protocol converter, and the protocol 
5 converter calls an entry point 412 within itself. The 
search request made by the client includes a template 
which specifies a pattern that the files must match be- 
fore being returned to the client. The template contains 
both characters from an allowed file name character set 
10 listed previously and wild cards. The wild cards are char- 
acters which are not allowed as part of a file name and 
have special meaning. In the illustrated embodiment, 
the wild card characters are (asterisk) and "?" (ques- 
tion mark). An * will match any number of characters 
75 whereas a ? will match any one character or no charac- 
ters. Then, the protocol converter performs the cursory 
authorization checks described above (step 454), and if 
the client is authorized to search the directory (decision 
456), the protocol converter calls the lock manager to 
20 lock the directory against updates while the contents are 
being read (step 458). This lock is a shared read lock 
which permits other clients to concurrently read the 
same directory. Then the protocol converter 34 calls the 
file manager to obtain the contents of the directory (step 
25 460), and the file manager reads the contents of the di- 
rectory into data buffer 115 with assistance from the de- 
vice controller 119. Then, the protocol converter calls 
the lock manager to unlock the directory (step 462), 
thereby allowing other clients to update the directory. If 
30 one or more of the file names obtained from the directory 
matches the template, it will be included in the list of files 
returned to the client pursuant to the client search re- 
quest. Otherwise, the file name will not be included in 
the response to the client. The protocol converter 34 
55 then decides if the entire list of entries from the directory 
has been compared to the template (decision 466), and 
if so responds to the client with all of the entries which 
match the template (step 474). However, if the entire list 
has not been compared to the template, then the proto- 
40 col converter makes the comparison for the next entry 
obtained from the directory and if the entry matches the 
template (decision 468), determines if this entry (in ad- 
dition to the previous one), will exceed the capability of 
the client (decision 470). For example, if the client is the 
45 DOS client 14a, then the client can only handle file 
names within the confines of the 8.3 data format. Ac- 
cording to this format, each file name includes a period 
as a separator, and there must be 1 -8 characters pre- 
ceding the period and 0-3 characters following the sep- 
50 arator. Therefore, if the file name from the directory ex- 
ceeds the confines of the client data format, then the file 
name will not be returned to the client. If not, then this 
additional entry which matches the client template is re- 
turned to the client (step 472). Then, the protocol con- 
55 verter performs the foregoing decisions and steps for 
the remaining entries received from the directory. 
[0048] Figs. 4(a-e) illustrate general operation of the 
NFS protocol converter 36. In step 500, the protocol 
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converter 36 receives a client request through a com- 
munications routing function such as VM IUCV and the 
routing process 201 which correlates the NFS client to 
the appropriate protocol converter which in this case is 
protocol converter 36. s 
[0049] Protocol converter 36 receives a clients re- 
quest to create a file, and calls a create subroutine at 
entry point 504 (step 502). Next, as illustrated in Fig. 4 
(b), the protocol converter 36 determines if this client is 
authorized to add files to the common file system. For 10 
the NFS protocol, the client authorization is checked 
against the specified directory only. If the client is au- 
thorized to create a file in this directory (decision 512), 
then the protocol converter calls the file manager 30 to 
locate the file and return a handle or token based on the is 
name (step 514). If the file name already exists, then the 
file manager returns an error indication. However, if the 
file name has not already been used, then the file man- 
ager returns an indication of availability of the file name 
and a handle or token associated with the file name, and 20 
the protocol converte r proceeds to call the lock manager 
with a request to lock the file name (step 518). After the 
lock is obtained, the protocol converter calls the file 
manager to actually create the file (step 520), and if the 
file is successfully created (decision 522), then the pro- 2s 
tocol converter responds to the client with an indication 
of success and the file token question mark (step 524). 
Then, the protocol converter calls the file manager to 
close the file (step 525), and then calls the lock manager 
to unlock the file (step 526). Finally, the protocol con- 30 
verier calls the file manager to return the handle asso- 
ciated with the file name (step 527) so that other clients 
can access the file. It should be noted that according to 
the NFS protocol, each client request is considered to 
be atomic and self contained whereby files are automat- 3S 
ically opened before performing these specific client re- 
quests and then closed after performing these specific 
client requests. In contrast, according to the SMB pro- 
tocol, when a file is opened by a client it remains open 
so that the client can subsequently request a read or 40 
write operation (without repeating the open operation), 
until specifically closed by the client. It should also be 
noted that protocol converter 36 can be optimized by 
installing a delay before each call to the file manager to 
close a file. This delay provides time for the client to 4$ 
make another write or read request to the same file be- 
fore the file is closed. In such a case, unnecessary file 
closes and file opens are avoided. 
[0050] Referring again to Fig. 4(a), a client requests 
to read from a file is received in step 500, and the pro- so 
tocol converter calls the read subroutine 506 (step 502). 
Then, the protocol converter 36 calls the file manager 
30 to locate the file and return a token or handle based 
on the file name (step 528). The client request includes 
a token or handle which identifies the file. If the file exists ss 
(decision 530), then the protocol converter determines 
if the client is authorized to access this file (decision 
532). If so, then the protocol converter calls the lock 



manager to lock the file for reading, i.e. other clients can 
also read but not update the file concurrently (step 534). 
It should be note that the use of the common lock man- 
ager 105 for all of the shared files by all of the protocol 
converters 34, 36, 38 and 46 facilitates sharing of the 
common files and the common directory. If the lock was 
successfully established (decision 536), then the proto- 
col converter calls the file manager to open the file (step 
538). Next, the protocol converter 36 calls the file man- 
ager to read data from the file into the buffer 115 (step 
540). After the file manager copies the data into the data 
buffer with assistance from the DASD controller 119, 
then the protocol converter returns the data to the client 
(step 542). Then, the protocol converter calls the file 
manager to close the file and then calls the lock man- 
ager to unlock the file (step 544). Finally, the protocol 
converter performs other cleanup, i.e. freeing control 
blocks and other working storage (step 545). 
[0051] Referring again to Fig. 4(a), a client request to 
write to a file is passed to the protocol converter 36, and 
the protocol converter calls its write subroutine at entry 
point 508 (step 502). Then, the protocol converter 36 
calls the file manger 30 to locate the file and return a 
token or handle based on the file name contained in the 
client request (step 546). If the file presently exists (de- 
cision 548), then the protocol converter determines if 
this client is authorized to access this file (decision 550). 
If so, the protocol converter calls the lock manager to 
lock the file for a read operation (step 552). The lock 
manager returns an indication of the success or failure 
of the lock operation, and if the lock was successfully 
established on the named file (decision 554), then the 
protocol converter calls the file manager to open the file 
(step 556). Next, the protocol converter calls the file 
manager to write data into the file, which data was sup- 
plied with the client request and temporarily stored in 
the data buffer 1 1 5 (step 558). In response, the file man- 
ager writes the data into DASD 23 with assistance from 
the DASD controller 119. Then, the protocol converter 
responds to the client with an indication of the success 
of the write operation (step 560) and then calls the file 
manager to close the file (step 561 ), and then calls the 
lock manager to unlock the file (step 562). Finally, the 
protocol converter performs other cleanup (step 563). 
[0052] Referring again to Fig. 4(a), a client request to 
read the directory is received by the protocol converter 
36, and the protocol converter calls its read subroutine 
at entry point 510 (step 502). Then, the protocol con- 
verter 36 determines if the named object is in fact a di- 
rectory (decision 564), and if so determines if the user 
has authority to read the directory (decision 566). It 
should be noted that because the NFS data format is 
the most permissive of the three, that all of the file names 
within the directory will be ultimately returned to the cli- 
ent. If the client has the requisite authority, then the pro- 
tocol converter calls the lock manager to lock the direc- 
tory against updates while it is being read (step 568). If 
the lock was successful (decision 570), then the protocol 
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converter 36 reads the contents of the directory into the 
buffer 115 (step 572). Then, the protocol converter calls 
the lock manager to unlock the directory to allow other 
clients to update the directory (step 574). Finally, the 
protocol converter returns to the client all of the entries 
within the directory (step 576). 
[0053] Figs. 5(a-e) illustrate general operation and 
function of protocol converter 46 according to the 
present invention. In step 600, protocol converter 46 re- 
ceives a request from host application 26, possibly 
through a communications routing function such as AP- 
PC/VM. In step 602, protocol converter 46 routes the 
request to a corresponding handler which handler be- 
gins execution at a respective entry point. 
[0054] Fig. 5(b) illustrates the request handler within 
the protocol converter 46 for a create request. The re- 
quest handler begins at entry point 604, and then the 
protocol converter 46 determines if the host application 
is authorized to add a file to the file repository, both in 
general and with respect to the directory specified in the 
request. If the host application has such permission, 
then the protocol converter calls the file manager 30 to 
locate the file and return a handle or token correspond- 
ing to the file name (step 616). If the file name is not 
available, i.e. the file name is already being used, then 
the file manager returns an error, and the protocol con- 
verter passes the error to the client and performs appro- 
priate cleanup including a call to the file manager to re- 
turn the token associated with the file name (step 621). 
However, if the file is available, then the protocol con- 
verter calls the lock manager to lock the file token and 
structures associated with the file (step 620). Then, the 
protocol converter 36 calls the file manager to create the 
file (622). If the file is successfully created (decision 
624), then the protocol converter responds to the client 
with an indication of success, and returns any tokens or 
other information needed by the client (step 626). How- 
ever, if the file has not been created, then the protocol 
converter calls the file manager to return the handle or 
token, and responds to the client with an indication of 
the error (step 628). 

[0055] Referring again Fig. 5(a), a request by host ap- 
plication 26 to locate a file and return a handle or token 
based on the file name is received by the protocol con- 
verter 46 (step 600), and routed to an open subroutine 
which begins at entry point 606. As illustrated in Fig. 5 
(c), the protocol converter 46 next calls the file manager 
30 to locate the file and associate a token with it (step 
630). If the file does not currently exist (decision 632), 
then the protocol converter responds to the client with 
an indication of failure, and performs appropriate clean- 
up including a call to the file manager to return the token 
associated with the file name (step 633). However, if the 
file currently exists, then the protocol converter deter- 
mines if the host application is authorized to open the 
file (decision 634). If the host application is authorized, 
then the protocol converter calls the lock manager to 
lock the file token and structures associated with the file 



(step 636). However, if the file is already locked to the 
exclusion of the host application 26, then the protocol 
converter responds to the host application with an indi- 
cation of failure and performs appropriate cleanup, i.e. 

5 returning tokens and unlocking the file (step 644). How- 
ever, if the lock operation is successful, then the protocol 
converter calls the file manager to open the file (step 
640), responds to the host application with an indication 
of success of the open operation, and passes to the host 

10 application the token or handle associated with the file 
name (step 642). 

[0056] Referring again to Fig. 5(a), a request by host 
application 26 to read from the file is received by the 
protocol converter 46 (step 600), and protocol converter 

is 46 then calls the read subroutine which begins at entry 
point 608. Then, the protocol converter 46 begins the 
read subroutine by calling the file manager 30 to read 
the data specified in the request into the data buffer 115 
(step 646). In the illustrated example, the file for which 

20 the host application requests the read operation is the 
same file that was previously created and opened, and 
was referenced by the client in step 600 by the token or 
handle that was returned to the client after completion 
of the create and open operations. If the read operation 

25 js successful (decision 648), then the protocol converter 
46 responds to the client with the data (step 650), but if 
not, response to the client with an indication of failure 
(step 651). 

[0057] Referring again to Fig. 5(a), the protocol con- 
30 verter 46 now receives a request from the client to write 
to the same file (step 600), and the protocol converter 
46 calls the write subroutine which begins at entry point 
610. To begin the write subroutine, the protocol convert- 
er 46 calls the file manager to write the data included in 
35 the host application request to the named file (step 654). 
In the illustrated example, the file specified in the re- 
quest is the same file that was previously created, 
opened and read, and the host application request in- 
cludes the token or handle that was returned to the client 
40 after the create and open requests were completed. If 
the file manager successfully writes the data into the 
shared files (step 656), then the protocol converter re- 
sponds to the client with an indication of success (step 
658), but if not, respond to the client with an indication 
45 of failure (step 659). 

[0058] Referring again to Fig. 5(a), the protocol con- 
verter 46 receives a request from the host application 
26 to verify the existence of a named file (step 600), and 
the protocol converter 46 calls the exist subroutine 
50 which begins at entry point 612. Then, the protocol con- 
verter 46 calls the file manager 30 to locate the file and 
return the handle or token based on the file name (step 
660). If the file does not exist, then the protocol converter 
responds to the client with an indication of failure, and 
55 calls the file manager to return the handle or token (step 
667). However, if the file exists, then the protocol con- 
verter 46 calls the file manager to retrieve information 
about the file such as the times and dates of access, file 
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attributes, and other statistics and quantities relating to 
the file (step 664). Finally, the protocol converter re- 
sponds to the client with an indication of success of the 
exist request, and also responds with the information 
about the file (step 666). 

[0059] Based on the foregoing, a computer system 
according to the present invention has been disclosed. 
However, numerous modifications and substitutions can 
be made without deviating from the scope of the present 
invention. For example, other protocol converters for 
other types of clients can be added. Therefore, the in- 
vention has been disclosed by way of illustration and not 
limitation, and reference should be made to the following 
claims to detemine the scope of the present invention. 



Claims 

1 . A computer system for managing files or other data 
objects shared by first and second heterogeneous 
clients, said first client exhibiting a first communica- 
tion protocol and said second client exhibiting a sec- 
ond, different communication protocol, said system 
comprising: 

first protocol converter means, coupled to the 
first client to receive requests exhibiting said 
first protocol from said first client to create, read 
and write the files or other data objects, for con- 
verting said requests to corresponding re- 
quests in a common protocol; 

second protocol converter means, coupled to 
the second client to receive requests exhibiting 
said second protocol from said second client to 
create, read and write the files or other data ob- 
jects, for converting said requests to corre- 
sponding requests exhibiting said common pro- 
tocol; 

file manager means, coupled to said first and 
second protocol converter means to receive the 
converted requests exhibiting said common 
protocol from said first and second protocol 
converters, for executing said converted re- 
quests in a name space and data area which 
are both common to said first and second cli- 
ents, said name space storing names of said 
file or other data objects and said data area 
storing said files or other data objects, said file 
manager means providing access by each of 
said clients to names of said files or other data 
objects created by the other client, and access 
by each of said clients to said files or other data 
objects written by the other client. 

2. Computer system as set forth in claim 1 further com- 
prising lock manager means, common to both of 
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said protocol converters and callable by both of said 
protocol converters with said common protocol, for 
locking names of said files or other data objects 
throughout said name space and said files or other 
data objects, throughout said data area during ac- 
cess by each of said clients to prevent conflicting 
access by the other client. 

Computer system as set forth in claim 1 or 2 wherein 
said file manager means supports requests by each 
of said clients, after protocol conversion by the re- 
spective protocol converter, to delete a name of a 
file or other data object created by the other client 
and the associated file or other data object written 
by said other client. 



Computer system as set forth in claim 1, 
wherein 



2 or 3 



said file manager means also manages access 
by said first client to a second name space for 
names of other files or other data objects and 
a second data area for said other files or other 
data objects dedicated to said first client and 
not accessible by said said second client, and 
manages access by said second client to a third 
name space for names of other files or other 
data objects and a third data area for said other 
files or other data objects dedicated to said sec- 
ond client and not accessible by said first client; 

said first client makes said requests to said first 
protocol converter means to access said sec- 
ond name space and said second data area us- 
ing said first protocol and said first protocol con- 
verter means converts said requests to re- 
quests exhibiting said common protocol and 
passes the converted requests exhibiting said 
common protocol to said file manager means 
for execution; and 

said second client makes said requests to said 
second protocol converter means to access 
said third name space and said third data area 
using said second protocol and said second 
protocol converter means converts said re- 
quests to requests exhibiting said common pro- 
tocol and passes the converted requests exhib- 
iting said common protocol to said file manager 
means for execution. 

Computer system as set forth in claim 1 , 2, 3 or 4 
wherein said first client exhibits an SMB protocol 
and said first protocol converter supports the SMB 
protocol, and said second client exhibits an NFS 
protocol and said second protocol converter sup- 
ports the NFS protocol. 
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6. Computer system as set forth in claim 1 or one of 
the claims 2 to 5 wherein said file manager means 
executes within a host computer, said first client is 
a remote workstation or personal computer and 
said second client is an application executing within 5 
said host computer. 

7. Computer system as set forth in claim 1 or one of 
the claims 2 to 6 further comprising routing program 
means, coupled to receive said requests from said 10 
first and second clients exhibiting said first and sec- 
ond protocols, respectively, for routing said re- 
quests to said first and second protocol converters, 
respectively, based on the type of client which 
makes said request. is 



Patentanspruche 

1. Rechnersystem fOr die Verwartung von Dateien 20 
oder anderen Datenobjekten, die von ersten und 
zweiten heterogenen Clients gemeinsam genutzt 
werden, wobei der erste Client Ober ein erstes 
Ubertragungsprotokollverfugt undderzweite Client 
Ober ein zweites, davon abweichendes Ubertra- 25 
gungsprotokoll verfugt, wobei das System folgen- 
des umfaGt: 

ein erstes Protokollwandlermittel, das mit dem 
ersten Client verbunden ist, urn Anforderungen 30 
mit dem ersten Protokoll von dem ersten Client 
zu empfangen, urn die Dateien oder anderen 
Datenobjekte zu erstellen, zu lesen oder zu 
schreiben, mit dem die Anforderungen in ent- 
sprechende Anforderungen mit einem gemein- 35 
samen Protokoll umgewandelt werden; 

ein zweites Protokollwandlermittel, das mit 
dem zweiten Client verbunden ist, um Anforde- 
rungen mit dem zweiten Protokoll von dem 40 
zweiten Client zu empfangen, um die Dateien 
oder anderen Datenobjekte zu erstellen, zu le- 
sen oder zu schreiben, mit dem die Anforderun- 
gen in entsprechende Anforderungen mit dem 
gemeinsamen Protokoll umgewandelt werden; 45 

ein Dateiverwaltermittel, das mit den ersten 
und zweiten Protokoll wandlermitteln verbun- 
den ist, um die umgewandelten Anforderungen 
mit dem gemeinsamen Protokoll von den er- so 
sten und zweiten Protokollwandlern zu emp- 
fangen, mit dem die umgewandelten Anforde- 
rungen in einem Namensbereich und Datenbe- 
reich ausgefuhrt werden, die die ersten und 
zweiten Clients gemeinsam haben, wobei in ss 
dem Namensbereich die Namen der Daten 
oder der anderen Datenobjekte gespeichert 
sind und wobei in dem Datenbereich die Datei- 
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en oder anderen Datenobjekte gespeichert 
sind, wobei das Dateiverwaltermittel den Zu- 
griff eines jeden der beiden Clients auf die Na- 
men der Dateien oder anderen Datenobjekte 
ermoglicht, die von dem anderen Client erstelft 
wurden, sowie den Zugriff von jedem der Cli- 
ents auf die Dateien oder anderen Datenobjek- 
te ermoglicht, die von dem anderen Client ge- 
schrieben wurden. 

2. Rechnersystem nach Anspruch 1, das weiter ein 
Mittel fur die Sperrverwaltung umfaGt, das die bei- 
den Protokollwandler gemeinsam haben und das 
von beiden Protokollwandlern mit dem gemeinsa- 
men Protokoll aufgerufen werden kann, mit dem die 
Namen der Dateien oder anderen Datenobjekte in 
dem Namensbereich sowie die Dateien und ande- 
ren Datenobjekte in dem Datenbereich gesperrt 
werden konnen, wenn einer der beiden Clients dar- 
auf zugreift, um einen Konflikt durch einen gleich- 
zeitigen Zugriff des anderen Clients zu verhindern. 

3. Rechnersystem nach Anspruch 1 oder 2, worin das 
Dateiverwaltermittel nach der Protokollumwand- 
lung durch den entsprechenden Protokollwandler 
Anforderungen von jedem der beiden Clients unter- 
stutzt, um einen Namen einer Datei oder eines an- 
deren Datenobjekts, die bzw. das von dem anderen 
Client erstellt wurde, sowie die zugehdrige Datei 
oder das andere Datenobjekt zu loschen, das von 
dem anderen Client geschrieben wurde. 

4. Rechnersystem nach Anspruch 1, 2 oder 3, worin 

das Daterverwaltermrttel auBerdem den Zugriff 
des ersten Clients auf einen zweiten Namens- 
bereich fur Namen von anderen Dateien oder 
anderen Datenobjekten sowie auf einen zwei- 
ten Datenbereich fur die anderen Dateien oder 
anderen Datenobjekte verwaltet, die fur den er- 
sten Client reserviert sind und auf die der zwei- 
te Client nicht zugreifen kann, und auGerdem 
den Zugriff des zweiten Clients auf einen dritten 
Namensbereich fur Namen von anderen Datei- 
en oder anderen Datenobjekten sowie auf ei- 
nen dritten Datenbereich fur die anderen Datei- 
en oder anderen Datenobjekte verwaltet, die 
fur den zweiten Client reserviert sind und auf 
die der erste Client nicht zugreifen kann; 

der erste Client die Anforderungen an das erste 
Protokollwandlermittel ausgibt, um auf den 
zweiten Namensbereich und den zweiten Da- 
tenbereich unter Verwendung des ersten Pro- 
tokolls zuzugreifen, und das erste Protokoll- 
wandlermittel die Anforderungen in Anforde- 
rungen umwandelt, die Ober das gemeinsame 
Protokoll verfugen, und die umgewandelten 
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Anforderungen mit dem gemeinsamen Proto- 
koll zur Ausf uhrung an das Dateiverwaltermittel 
weiterleitet; und 

der zweite Client die Anforderungen an das 
zweite Protokollwandlermittel ausgibt, um auf 
den dritten Namensbereich und den dritten Da- 
tenbereich unter Verwendung des zweiten Pro- 
tokolls zuzugreifen, und das zweite Protokoll- 
wandlermittel die Anforderungen in Anforde- 
rungen umwandelt, die uber das gemeinsame 
Protokoll verfugen, und die umgewandelten 
Anforderungen mit dem gemeinsamen Proto- 
koll zur Ausf uhrung an das Dateiverwaltermittel 
weiterleitet. 

Rechnersystem nach Anspruch 1 , 2, 3, Oder 4, wor- 
in der erste Client uber ein SMB-Protokoll verfugt 
und der erste Protokollwandler das SMB-Protokoll 
unterstutzt und worin der zweite Client uber ein 
NFS-Protokoll verfugt und der zweite Protokoll- 
wandler das NFS-Protokoll unterstutzt. 

Rechnersystem nach Anspruch 1 oder einem der 
Anspruche 2 bis 5, worin das Dateiverwaltermittel 
in einem Hostrechner ausgefuhrt wird, wobei der er- 
ste Client eine entfemte Arbeitsstation oder ein Per- 
sonal Computer und der zweite Client eine Anwen- 
dung ist, die in dem Hostrechner ausgefuhrt wird. 

Rechnersystem nach Anspruchl oder einem der An- 
spruche 2 bis 6, das we iter ein Leitwegprogrammit- 
tel umfaGt, das so verbunden ist, daQ es die Anfor- 
derungen von dem ersten zweiten Client mit dem 
ersten bzw. zweiten Protokoll empfangt, um die An- 
forderungen, abhangig vom Clienttyp, der die An- 
forderung ausgibt, an den ersten bzw. zweiten Pro- 
tokollwandler weiterzuleiten. 



Revendications 

1. Un systeme d'ordinateur pour la gestion desfichiers 
ou d'autres objets constitues de donnees, partages 
par des premier et deuxieme clients heterogenes, 
ledit premier client presentant un premier protocole 
de communication et ledit deuxieme client presen- 
tant un deuxieme protocole de communication, dif- 
ferent, ledit systeme comprenant : 

des premiers moyens de conversion de proto- 
cole, couples au premier client pour recevoir 
des requetes presentant ledit premier protocole 
venant dudit premier client, pour creer, lire et 
ecrire les fichiers ou d'autres objets constitues 
de donnees, pour convertir lesdites requetes 
en des requetes correspondantes sous un pro- 
tocole commun; 
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les deuxiemes moyens de conversion de pro- 
tocole, couples au deuxieme client, pour rece- 
voir des requites presentant ledit deuxieme 
protocole venant dudit deuxieme client, pour 
creer, lire et ecrire les fichiers ou d'autres objets 
constitute de donnees, pour convertir lesdites 
requetes en des requites correspondantes 
presentant ledit protocole commun; 

des moyens gestionnaires de fichiers, couples 
auxdits premiers et deuxiemes moyens de con- 
version de protocole pour recevoir les requetes 
converties presentant ledit protocole commun 
desdits premier et deuxieme convertisseurs de 
protocole, pour execute r lesdites requetes con- 
verties dans un espace de nom et une zone de " 
donnees qui, les deux, sont communs auxdits 
premier et deuxieme clients, ledit espace de 
nom stockant les noms dudit fichier ou d'autres 
objets constitues de donnees, et ladite zone de 
donnees stockant lesdits fichiers ou d'autres 
objets constitues de donnees, lesdits moyens 
gestionnaires de fichiers donnant acces, par 
chacun desdits clients, aux noms desdits fi- 
chiers ou a d'autres objets constitues de don- 
nees ayant ete crees par I'autre client et don- 
nant acces par chacun desdits clients auxdits 
fichiers ou a d'autres objets constitues de don- 
nees ayant ete ecrits par I'autre client. 

Systeme d'ordinateur selon ia revendication 1, 
comprenant en outre des moyens gestionnaires de 
verrouillage, communs aux deux desdits convertis- 
seurs de protocole et pouvant etre appeies par les 
deux dits convertisseurs de protocole avec ledit 
protocole commun, pour verrouiller les noms des- 
dits fichiers et d'autres objets constitues de don- 
nees dans ledit espace de nom et lesdits fichiers ou 
d'autres objets constitues de donnees, dans ladite 
zone de donn6es durant I'acces par chacun desdits 
clients, afin d'empecher tout acces conflictuel par 
I'autre client. 

Systeme d'ordinateur selon la revendication 1 ou 2, 
dans lequel lesdits moyens gestionnaires de fichier 
supportent des requetes emises par chacun desdits 
clients, apres la conversion de protocole par le con- 
vertisseurde protocole respectif, poursupprimerun 
nom d'un fichier ou un autre objet constitue de don- 
nees ayant et6 cree par I'autre client et le fichier as- 
socie ou un autre objet constitue de donnees ecrit 
par ledit autre client. 

Systeme d'ordinateur selon la revendication 1, 2ou 
3, dans lequel 

lesdits moyens gestionnaires de fichiers gerent 
egalement I'acces, par ledit premier client, a un 
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deux.eme espace de nom, pour des noms 
dautres fichiers ou d'autres objets constitues 
de donnees, et a une deuxieme zone de don- 
nees, pour lesdits autres fichiers ou autres ob- 
lets constitues de donnees dedies audit pre- 
mier client et non-accessibles par ledit deuxie- 
me client, et gerent I'acces par ledit deuxieme 
client a un troisieme espace de nom, pour des 
noms d'autres fichiers ou d'autres objets cons- 
trtues de donnees, et a une troisieme zone de 
donnees, pour lesdits autres fichiers ou 
dautres objets constitues de donnees, dedies 
audit deuxieme client et non-accessibles par le- 
dit premier client; 

ledit premier client produit lesdites requetes 
destinees auxdit premiers moyens convertis- 
seurs de protocole, pour acceder audit deuxie- 
me espace de nom et a ladite deuxieme zone 
de donnees, par utilisation dudit premier proto- 
cole, et lesdits premiers moyens convertisseur 
de protocole convertissent lesdites requetes en 
des requetes presentant ledit protocole com- 
mun et passant les requetes converties presen- 
tant ledrt protocole commun auxdits moyens 
gestionnaires de fichier en vue de ('execution- 
et ' 
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I une des revendications 2 a 6, comprenant en outre 
des m oy e ns de programme d'acheminement cou- 
ples pour recevoir lesdites requetes venant desdits 
premier et deuxieme clients presentant lesdits pre- 
mier et deuxieme protocoles, respectivement pour 

achemmer lesdites requetes vers lesdits premiere, 
deuxieme convertisseurs de protocole, respective- 

s :zT anx sur ,e * pe de c,ient produisant 
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ledit deuxieme client produit lesdites requetes 
auxdrts deuxiemes moyens convertisseurs de 
protocole, pour I'acces audit troisieme espace 
de nom et a ladite troisieme zone de donnees 
par utilisation dudit deuxieme protocole, et les- 
dits deuxiemes moyens convertisseur de pro- 
tocole convertissent lesdites requetes en des 
requetes presentant ledit protocole commun et 
passant les requetes converties presentant le- 
dit protocole commun auxdits moyens gestion- 
naires de fichier pour I'execution. 

Systemed'ordinateurselonlarevendicatiom 2 3 
ou 4, dans lequel cheque premier client presente 
un protocole Bloc Message Serveur (SMB) et ledit 

, P ^7 e L^ VertiSSeUrde protocole su PP°*e 'e Pro- 
mote SMB. et ledi, deuxieme Cent presente un 
protocole Systems Ficher Rfoeau (NFS) et ledit 
deux.eme convertisseur de protocole supporte le 
protocole NFS. K 
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Systeme dordinateur selon la revendication 1 ou so 
I une des revendications 2 a 5, dans lequel lesdits 
moyens gestionnaires de fichier executent leurs 
fonctions dans un ordinateur hole, ledit premier 
client est un poste de travail ou un ordinateur per- 
sonnel distant et ledit deuxieme client est une ap- ss 
plication s'executant dans ledit ordinateur hole. 

Systeme d'ordinateur selon la revendication 1 ou 
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